📝 今日目標

今天想繼續完善 AI 保健小幫手，新增「家人朋友」功能。

除了讓使用者管理自己的健康紀錄，我也希望未來可以讓家人或朋友互相加好友、傳送訊息，並在適當的情況下關心彼此的健康狀況。

不過，這次除了設計介面，也開始接觸 Supabase 的資料庫權限與使用者資料安全。

🛠️ 今天做了什麼？

1. 建立家人朋友頁面

首先，我使用 Codex 開發家人朋友功能的介面，規劃了幾個主要區域：

• 使用者 ID
• QR Code
• 新增好友
• 好友邀請
• 好友列表
• 聊天訊息
• 好友關懷通知

希望之後可以透過使用者 ID 或 QR Code 新增好友，並透過邀請機制決定是否接受交友。

目前已經完成相關介面的建置，並將更新部署到原本的 Netlify 網站。

不過，介面完成不代表所有功能都已經能正常運作，接下來還需要逐一完成資料庫串接與實際測試。

2. 串接 Supabase Email 登入

為了讓好友功能能夠辨識不同使用者，我開始整合 Supabase 的 Email 登入功能。

目前已經測試過 Email 登入，並且可以取得使用者的 UUID。

UUID 是使用者的唯一識別碼，之後可以用來辨識好友邀請的發送者與接收者。

例如：

• A 使用者想新增 B 使用者為好友。
• A 輸入 B 的 UUID。
• B 收到好友邀請。
• B 可以選擇接受或拒絕。

這樣就能建立基本的好友邀請流程，而不只是讓按鈕停留在畫面上。

3. 檢查好友相關資料表

接著，我進入 Supabase Dashboard，確認好友功能需要使用的資料表是否存在。

目前已確認有以下四張資料表：

其中，friend_requests 負責記錄邀請狀態，而 friendships 則用來保存已經成立的好友關係。

將這些資料分開管理，可以讓好友邀請與正式成為好友這兩件事有明確的區別。

4. 研究 RLS 與資料庫權限

今天花了不少時間檢查 Supabase 的安全設定。

一開始，我以為只要資料表存在，而且已經設定 RLS，就代表前端可以正常存取資料。

但實際檢查後，才發現還有其他需要確認的設定。

RLS 與資料庫權限並不是同一件事。

• GRANT 權限： 決定某個角色是否有權限執行資料表或函式操作。
• RLS： 在允許操作的前提下，進一步限制使用者可以存取哪些資料列。
• Data API 曝露設定： 決定哪些資料表與函式可以透過 Data API 提供存取。

即使 RLS 政策設定正確，如果缺少必要的資料庫權限，前端仍然可能無法正常查詢資料。

這也讓我了解到，開發網站不只是把功能做出來，還必須確認前端、API 與資料庫之間的權限是否正確。

5. 確認好友邀請的安全機制

除了資料表權限，我也檢查了好友邀請相關的資料庫設定。

目前已確認：

• 好友邀請有對應的 RLS 政策。
• 待處理邀請具有避免雙向重複邀請的唯一索引。
• 好友關係的讀取受到限制。
• 使用者只能修改自己的暱稱。
• 接受或拒絕好友邀請的資料庫函式已經存在。
• 新使用者註冊時，已有建立個人 profile 的 trigger。

其中，接受好友邀請的函式會檢查邀請是否仍處於待處理狀態，以及執行操作的人是否為邀請接收者。

這些限制可以降低使用者任意修改好友關係的風險。

不過，目前仍需要進一步確認 Data API 曝露與資料庫權限，並透過兩個真實帳號測試完整流程。

因此，今天先完成檢查與權限修正方案的整理，尚未執行 SQL，也沒有宣稱好友邀請已經全部測試成功。

💡 今日心得

今天最大的收穫，是發現開發一個功能不只是完成介面與 JavaScript。

以好友功能為例，畫面上即使已經有新增好友、接受邀請和好友列表，如果資料庫權限沒有設定好，這些功能仍然可能無法正常使用。

另外，健康紀錄涉及個人資料，因此不能只追求方便，也需要考慮資料隔離。

例如，使用者應該只能修改自己的通知偏好，也不應該任意讀取其他人的私人資料。

這次的開發讓我開始理解，功能能夠執行很重要，但資料安全同樣是系統設計的一部分。

接下來，我會先處理必要的資料庫權限，再使用兩個帳號測試好友邀請、接受、拒絕與好友清單，確認基本流程正常後，才繼續開發其他功能。

🔜 明日預告

明天預計開始開發 AI 保健小幫手的寵物養成與個人化功能。

希望讓使用者在完成健康紀錄後，可以透過餵養、累積經驗值及解鎖外觀等方式，增加使用健康紀錄工具的趣味性。

同時，也會開始調整寵物頁面與家人朋友頁面的 RWD 響應式設計，讓網站在不同尺寸的裝置上都能更方便使用。

接下來還有不少功能需要整合，希望能一步步把目前的介面，變成真正能使用的個人健康紀錄工具。